1. Technical Field of the Invention
The present invention relates in general to data networks, and in particular, to managing traffic priority in data networks.
2. Description of Related Art
When configuring a data network, a network administrator needs to be able to guarantee a certain Quality of Service (QoS) for customers as outlined in Service Level Agreements (SLAs) with those customers. To enforce a particular QoS, a separate priority is assigned to each class of traffic, and depending on the assigned priority, different processing may be performed on that traffic. Normally, higher priority traffic is expected to perform better in terms of bandwidth, loss, delay, delay variation, and other traffic parameters, which in turn results in a higher price billed to the customer.
The priority assigned to traffic is indicated in the headers of corresponding layers of that traffic. For example, in the header of an Internet Protocol (IP) packet, the traffic priority is indicated in the DiffServ Code Point (DSCP) field, in the header of an MPLS packet, the traffic priority is indicated in the EXPerimental (EXP) field and in the header of an Ethernet packet, the traffic priority is indicated by the p-bits or Priority Code Point (PCP) in Ethernet VLAN tags (802.1Q).
Initial traffic priority settings are performed at network ingress points. However, the initial priority setting may change during transport when a certain traffic priority class is multiplexed with other priority traffic flows. In addition, each network node within the network is configured to maintain or modify the priorities within a layer (intra-layer remarking or regeneration), and in the case of encapsulation/termination, to map the priorities between layers (inter-layer mapping). However, when a particular network layer (e.g., IP) is encapsulated in another layer (e.g., Ethernet) with its own designated priority, the priority of the outer layer may not match the payload priority of the original network layer (e.g., IP).
Initial priority configuration of network nodes is currently performed either manually by Network Management System (NMS) commands, by executing NMS rules (for instance, from a policy server) that automatically issue out-of-band commands, or by using network control protocols, e.g., when a virtual circuit, such as an MPLS LSP, is provisioned with CR-LDP or RSVP-TE. All of these initial priority configuration methods are subject to errors and mistakes, some with immediate effects and some only with latent effects.
Priority misconfigurations can also occur after the network node becomes operational. For example, during a routine check of the network node, the network administrator may type a wrong command that may not even be directed to priorities, which can cause a misconfiguration of the priority handling. As another example, if traffic is reorganized (for instance, a new Deep Packet Inspection capability is introduced in the nodes, and as a consequence, traffic classes can be classified with a finer granularity than previously, and priorities are to be mapped and converted differently), there may be a lot of intended priority handling changes, thus causing many opportunities for configuration errors. In addition, SLS and SLA updates may create the same opportunities for configuration errors.
As yet another example, if separate datapath tables are used and copied from the Management Information Base (MIB), their content may be different due to errors that may have occurred in the copy process from MIB to datapath memory. In addition, a line card could go down, then reboot, and fail to update certain datapath tables. Such an error could go unnoticed for an extended period of time. Likewise, memory overwrites as a result of poor resource allocation for different forwarding instances (e.g. VPLS case) may also go unnoticed until limits are reached for resources.
As a further example, if certain priorities are wrongly configured at certain nodes in the network, the network could still be operational, but certain classes of traffic may get better or worse treatment than intended. If the network is rarely or never saturated, premium traffic receiving only best-effort priority would not be noticed until congestion occurs in the network, suddenly exposing the problem. Likewise, low-priority traffic (e.g., residential user High Speed Internet service) could wrongly receive high-priority due to a single misconfiguration along the path, and peer-to-peer file downloads could end up monopolizing the bandwidth in the network. Moreover, if a customer subscribes to a higher priority service but the operator fails to reconfigure his/her RGW correctly, then the RGW could start marking new packets with wrong priority values, which would not be modified since the RGW is an operator-managed ingress node, trusted by the rest of the network.
With all of the potential ways in which priority settings can be misconfigured, a network operator typically must verify that the priority handling in the network nodes is set correctly and performs as expected, so that contractual SLAs can be satisfactorily delivered to the customers. Priority settings are currently verified by out-of-band queries, which return values from the node MIBs (Management Information Bases). However, out-of-band queries can miss datapath-related problems, since an out-of-band query only verifies the MIB content and not the datapath path tables copied into memory from the MIB in the network node.
In addition, in cases where an error occurs in the RGW, out-of-band queries not reaching the RGW may show that the priority configuration is correct in the rest of the network. Therefore a per-customer, per-service end-to-end check (reaching the RGW) would be desirable for the network operator to handle any customer complaints. Unfortunately, tracking a particular path with an out-of-band method can be tedious if many nodes are involved, since the network operator needs to log onto each node, and a separate command is necessary for each network layer processed by that node. In addition, in many cases, the network operator may not know the exact trajectory of the data path. Furthermore, the nodes along a data path may be managed by different network management systems, not necessarily integrated in the Operations Center, which makes the per-node logging process even more difficult for an administrator.
Therefore, what is needed is an in-band query method that can travel the actual data path and experience and collect all priority-related remarkings and mappings along the data path.